You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For now a little experimental, what to do some exploration and see if this could be a direction we can/should be going.
Extract Readme component from package page
This has the benefit of better separation of concerns. The data loading is also moved into the component. Since the Playground component needs the same data, both now do a fetch, but that gets deduplicated.
Add explicit loading and error state for Readme
This mainly fixes the issue of "There is no Readme appearing" when something goes wrong
As it is currently implemented I am not sure in which cases the loading state for the Readme would appear. We could load it non-blocking which would render the rest of the page faster so it can load in the background. I am not sure exactly though what the best way to do this in Nuxt is.
I think ideally the whole page should be rendered via SSR, if all the fetches have cached results. Otherwise a component like the readme component could be client side rendered to have faster time to interaction.
This pattern would also allow us to control the loading skeletons on a per component basis, while making it easier to already show headings etc.
If we would follow through with this the whole page could be small components, each fetching their own data, with Nuxt deduplication making sure we fetch the same thing twice. I have worked with a similar pattern in Next and I really liked it from a DX as well as from a UX perspective (because it makes it easier to show each thing as early as possible, without being blocked by other data that might be needed elsewhere).
Open questions
SWR. Currently you might see an outdated version of the readme, but it looks ready and then might change after a moment to the current version. Is that what we want? Shouldn't there at least be some indication that it's still refreshing?
I think someone mentioned that caching happens only for explicit version, but most package views will come from non-explicit version, so they will always have to get the correct version first?
There might also be some problem with the current setup and changes to be made, because I am not sure, if this way the Readme will start to fetch it's data before the main package page is ready.
Alternative approach would be to still load all the data in the main page component, but pass the fetch response object (including status and error) to the components to handle those correctly. This wouldn't change much about the data fetching, but would still allow for more granular loading state and error handling. Would also allow to test the loading state per component.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For now a little experimental, what to do some exploration and see if this could be a direction we can/should be going.
This has the benefit of better separation of concerns. The data loading is also moved into the component. Since the Playground component needs the same data, both now do a fetch, but that gets deduplicated.
This mainly fixes the issue of "There is no Readme appearing" when something goes wrong
As it is currently implemented I am not sure in which cases the loading state for the Readme would appear. We could load it non-blocking which would render the rest of the page faster so it can load in the background. I am not sure exactly though what the best way to do this in Nuxt is.
I think ideally the whole page should be rendered via SSR, if all the fetches have cached results. Otherwise a component like the readme component could be client side rendered to have faster time to interaction.
This pattern would also allow us to control the loading skeletons on a per component basis, while making it easier to already show headings etc.
If we would follow through with this the whole page could be small components, each fetching their own data, with Nuxt deduplication making sure we fetch the same thing twice. I have worked with a similar pattern in Next and I really liked it from a DX as well as from a UX perspective (because it makes it easier to show each thing as early as possible, without being blocked by other data that might be needed elsewhere).
Open questions